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Foreword 



rd , 



This Technical Specification (TS) has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document identifies and standardises the most important and strategic contexts in the physical architecture 
for the management of PLMNs. It serves as a framework to help define a telecom management physical architecture for 
a planned PLMN and to adopt standards and provide products that are easy to integrate. 

The requirements identified in the present document are applicable to all further development of 3 GPP Telecom 
Management specifications as well as the development of PLMN Management products. The present document can be 
seen as guidance for the development of all other Technical Specification addressing the management of PLMNs, 
except TS 32.101 [2]. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[I] ITU-T Recommendation M.3010 (2000): "Principles for a Telecommunications management 
network" . 

[2] 3GPP TS 32.101: "Telecommunication management; Principles and high level requirements". 

[3] Void. 

[4] ITU-T Recommendation X.200 (1994): "Information technology - Open Systems Interconnection - 

Basic Reference Model: The basic model". 

[5] 3GPP TS 32.150: "Telecommunication management; Integration Reference Point (IRP) Concept 

and definitions". 

[6] Void. 

[7] Void. 

[8] Void. 

[9] TMF GB910: "Smart TMN Telecom Operations Map (Release 2.1)". http://www.tmforum.org 

[10] TMF GB909: "Smart TMN Technology Integration Map (Issue 1.1)". http://www.tmforum.org 

[II] ITU-T Recommendation M.3013 (2000): "Considerations for a telecommunications management 
network". 

[12] 3GPP TS 23.002: "Network architecture". 

[13] 3GPP TS 23.101: "General UMTS Architecture". 

[14] 3GPP TS 32.111 parts 1 to 5: "Telecommunication management; Fault Management;". 

32.111-1 Partl:3G fault management requirements ' ' . 

32.1 1 1-2 Part 2: Alarm Integration Reference Point (IRP): Information Service (IS)". 
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32. 1 1 1-3 Part 3: Alarm Integration Reference Point (IRP): Common Object Request Broker 
Architecture (CORE A) Solution Set (SS)". 

32. 1 1 1-4 Part 4: Alarm Integration Reference Point (IRP): Common Management Information 
Protocol (CMIP) Solution Set (SS)". 

32.1 1 1-5 Part 5: Alarm Integration Reference Point (IRP): extensible Markup Language (XML) 
definitions". 

[15] OMG: "Unified Modelling Language Specification, Version 1.4, September 2001". 

http://www.omg.org/technology/documents/formal/uml.htm 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following definitions apply: 

architecture: organisational structure of a system or component, their relationships, and the principles and guidelines 
governing their design and evolution over time 

closed interfaces: privately controlled system/subsystem boundary descriptions that are not disclosed to the public or 
are unique to a single supplier 

de facto standard: standard that is widely accepted and used but that lacks formal approval by a recognised standards 
organisation 

Information Service (IS): Defined in 3GPP TS 32.150 [5]. interface standard: standard that specifies the physical or 
functional interface characteristics of systems, subsystems, equipment, assemblies, components, items or parts to permit 
interchangeability, interconnection, interoperability, compatibility, or communications 

interoperability: ability of two or more systems or components to exchange data and use information 

intra-operability: ability to interchange and use information, functions and services among components within a 
system 

Integration Reference Point (IRP): Defined in 3GPP TS 32.150 [5]. 

Managed Object: Defined in 3GPP TS 32.150 [5]. 

management infrastructure: Defined in TS 32.101 [2]. market acceptance: means that an item has been accepted in 
the market as evidenced by annual sales, length of time available for sale, and after-sale support capability. 

modular: pertaining to the design concept in which interchangeable units are employed to create a functional end 
product. 

module: interchangeable item that contains components. In computer programming, a program unit that is discrete and 
identifiable with respect to compiling, combining with other modules, and loading is called a module. 

Network Resource Model (NRM): Defined in 3GPP TS 32.150 [5]. 

open specifications: public specifications that are maintained by an open, public consensus process to accommodate 
new technologies over time and that are consistent with international standards 

open standards: widely accepted and supported standards set by recognised standards organisation or the commercial 
market place. These standards support interoperability, portability, and scalability and are equally available to the 
general public at no cost or with a moderate license fee. 

open systems strategy: focuses on fielding superior telecom capability more quickly and more affordably by using 
multiple suppliers and commercially supported practices, products, specifications, and standards, which are selected 
based on performance, cost, industry acceptance, long term availability and supportability, and upgrade potential. 
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physical architecture: minimal set of rules governing the arrangement, interaction, and interdependence of the parts or 
elements whose purpose is to ensure that a conformant system satisfies a specified set of requirements. The physical 
architecture identifies the services, interfaces, standards, and their relationships. It provides the technical guidelines for 
implementation of systems upon which engineering specifications are based and common building blocks are built. 

PLMN Organisation: see 3GPP TS 32.101 [2]. 

plug&play: term for easy integration of HW/SW 

portabihty: the ease with which a system, component, data, or user can be transferred from one hardware or software 
environment to another 

proprietary specifications: specifications, which are exclusively owned by a private individual or corporation under a 
trademark or patent, the use of which would require a license 

reference model: a generally accepted abstract representation that allows users to focus on establishing definitions, 
building common understandings and identifying issues for resolution. For TMN Systems acquisitions, a reference 
model is necessary to establish a context for understanding how the disparate technologies and standards required to 
implement TMN relate to each other. A reference model provides a mechanism for identifying the key issues associated 
with applications portability, modularity, scalability and interoperability. Most importantly, reference models will aid in 
the evaluation and analysis of domain- specific architectures. 

scalability: capability to adapt hardware or software to accommodate changing workloads 

service specific entities: entities dedicated to the provisioning of a given (set of) service(s). The fact that they are 
implemented or not in a given PLMN should have limited impact on all the other entities of the PLMN. 

Solution Set (SS): Defined in 3GPP TS 32.150 [5]. 

specification: document that prescribes, in a complete, precise, verifiable manner, the requirements, design, behaviour, 
or characteristics of a system or system component 

standard: document that establishes uniform engineering and technical requirements for processes, procedures, 
practices, and methods. Standards may also establish requirements for selection, application, and design criteria of 
material. 

standards based architecture: architecture based on an acceptable set of open standards governing the arrangement, 
interaction, and interdependence of the parts or elements that together may be used to form a TMN System, and whose 
purpose is to insure that a conformant system satisfies a specified set of requirements. 

Support IOC: defined in TS 32.150 [5]. 

system : any organised assembly of resources and procedures united and regulated by interaction or interdependence to 
accomplish a set of specific functions 

System Architecture (SA): description, including graphics, of systems and interconnections providing for or 
supporting management functions. The SA defines the physical connection, location, and identification of the key 
nodes, circuits, networks, platforms, etc., and specifies system and component performance parameters. It is constructed 
to satisfy Operational Architecture requirements per standards defined in the Physical Architecture. The SA shows how 
multiple systems within a subject area link and inter-operate, and may describe the internal construction or operations of 
particular systems within the architecture. 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

3G 3'^ Generation 

AAA Authentication, Authorisation and Accounting 

AN Access Network 

AS Application Server 

ATM Asynchronous Transfer Mode 

AUG Authentication Gentre 

BG Border Gateway 

BGGF Breakout Gateway Control Function 
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BM-SC Broadcast-Multicast Service Centre 

BSC Base Station Controller 

BSS Base Station Subsystem 

BTS Base Transceiver Station 

CAMEL Customised Applications for Mobile network Enhanced Logic 

CBC Cell Broadcast Center 

CB S Cell Broadcast Service 

CMIP Common Management Information Protocol 

CMIS Common Management Information Service 

CMISE Common Management Information Service Element 

CN Core Network 

CORBA Common Object Request Broker Architecture 

CRF Charging Rules Function 

CS Circuit Switched 

CSCF Call Session Control Function 

DCN Data Communication Network 

DECT Digital Enhanced Cordless Telecommunications 

DSSl Digital Subscriber System 1 

FIR Equipment Identity Register 

EM Element Manager 

E-OS Element Management Layer-Operations System 

FAV Firewall 

EM Fault Management 

FT AM File Transfer, Access and Management 

GCR Group Call Register 

GDMO Guidelines for the Definition of Managed Objects 

GGSN Gateway GPRS Support Node 

GMLC Gateway Mobile Location Center 

GMSC Gateway MSC 

GPRS General Packet Radio Service 

GTT Global Text Telephony 

HLR Home Location Register 

HSS Home Subscriber Server 

HTTP HyperText Transfer Protocol 

HW Hardware 

I-CSCF Interrogating CSCF 

IBCF Interconnection Border Control Function 

IDL Interface Definition Language 

HOP Internet Inter-ORB Protocol 

IMS IP Multimedia Subsystem 

INAP Intelligent Network Application Part 

IP Internet Protocol 

IRP Integration Reference Point 

IS Information Service 

ISDN Integrated Services Digital Network 

IWU Inter Working Unit 

LCS Location Services 

LMU Location Measurement Unit 

MBMS Multimedia Broadcast Multicast Service 

MD Mediation Device 

ME Mobile Equipment 

MGCF Media Gateway Control Function 

MIB Management Information Base 

MMI Man-Machine Interface 

MML Man-Machine Language 

MMS Multimedia Messaging Service 

MNP Mobile Number Portability 

MNP-SRF Mobile Number Portability/Signalling Relay Function 

MRF Multimedia Resource Function 

MRFC Multimedia Resource Function Controller 

MRFP Multimedia Resource Function Processor 

MSC Mobile service Switching Centre 
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MT Mobile Termination 

NE Network Element 

NM Network Manager 

N-OS Network Management Layer-Operations System 

NPDB Number Portability Database 

NR Network Resource 

NRM Network Resource Model 

NSS Network Switching Subsystem 

NW Network 

OMG Object Management Group 

OS Operations System 

OSA Open Services Access 

OSF Operations System Functions 

P-CSCF Proxy CSCF 

PDH Plesiochronous Digital Hierarchy 

PS Packet Switched 

PSA Product Specific Applications 

PSS Packet Switched Service 

PSTN PubHc Switched Telephone Network 

QA Q-Adapter 

QoS Quality of Service 

RNC Radio Network Controller 

RNS Radio Network System 

RSVP Resource Reservation Protocol 

S-CSCF Serving CSCF 

SDH Synchronous Digital Hierarchy 

SGSN Serving GPRS Support Node 

SGW Signalling Gateway 

SIM Subscriber Identity Module 

SLA Service Level Agreement 

SLF Subscription Locator Function 

SMI Structure of Management Information 

SMLC Serving Mobile Location Center 

SMS Short Message Service 

SNM Sub-Network Manager 

SNMP Simple Network Management Protocol 

SS Solution Set 

SS7 Signalling System No. 7 

SW Software 

TA Terminal Adapter 

TE Terminal Equipment 

TM Telecom Management 

TMN Telecommunications Management Network as defined in ITU-T Recommendation M.3010 [1] 

TrGW Transition Gateway 

UE User Equipment 

UML Unified Modelling Language 

US AT USIM/SIM AppHcation Toolkit 

USIM UMTS Subscriber Identity Module 

UTRA Universal Terrestrial Radio Access 

UTRAN Universal Terrestrial Radio Access Network 

VHE Virtual Home Environment 

VLR Visitor Location Register 

WAG WLAN Access Gateway 

WBEM Web Based Enterprise Management 

WS Workstation 
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4 General 

4.1 PLMN Telecom Management 

4.1 .1 3GPP Reference Model 

A 3 GPP System is made of the following components: 

one or more Access Networks, using different types of access techniques (GSM, UTRA, DECT, PSTN, 
ISDN, ...) of which at least one is UTRA; 

one or more Core Networks; 

- one or more Intelligent Node Networks, service logic and mobility management, (IN, GSM ...); 

one or more transmission networks (PDH, SDH etc) in various topologies (point-to-point, ring, 
point-to-multipoint etc) and physical means (radio, fibre, copper, etc.). 

The 3GPP system components have signalling mechanisms among them (DSSl, INAP, MAP, SS7, RSVP, etc.). 

From the service perspective, the 3 GPP system is defined to offer: 

- service support transparent to the location, access technique and core network, within the bearer capabilities 
available in one particular case; 

- user to terminal and user to network interface (MMI) irrespective of the entities supporting the services required 
(VHE); 

- multimedia capabilities. 

4.1.2 3GPP Provisioning Entities 

Two major entities, which cover the set of 3GPP functionalities involved in the provision of the 3GPP services to the 
user, are identified as follows: 

Home Environment: This entity holds the functionalities that enable a user to obtain 3 GPP services in a 
consistent manner regardless of the user's location or the terminal used. 

- Serving Network: This entity provides the user with access to the services of the Home Environment. 

4.1 .3 Management Infrastructure of the PLMN 

Every PLMN Organisation has its own Management Infrastructure. Each Management Infrastructure will contain 
different functionality depending on the role-played and the equipment used by that Entity. 

However, the core management architecture of the PLMN Organisation is very similar. Every PLMN Organisation: 

- provides services to its customers; 

- needs an infrastructure to fulfil them (advertise, ordering, creation, provisioning, ...); 

- assures them (Operation, Quality of Service, Trouble Reporting and Fixing, ...); 

- bills them (Rating, Discounting, ...). 

Not every PLMN Organisation will implement the complete Management Architecture and related Processes. Some 
processes may be missing dependent on the role a particular Organisation is embodying. Processes not implemented by 
a particular Organisation are accessed via interconnections to other organisations, which have implemented these 
processes (called X-interfaces in the TMN architecture). 

The Management architecture itself does not distinguish between external and internal interfaces. 
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4.2 TMN 

TMN (Telecommunications Management Network), as defined in [1], provides: 

- an architecture, made of OS (Operations Systems) and NEs (Network Elements), and the interfaces between 
them (Q, within one Operator Domain and X, between different Operators); 

- the methodology to define those interfaces; 

- other architectural tools such as LLA (Logical Layered Architecture) that help to further refine and define the 
Management Architecture of a given management area; 

- a number of generic and/or common management functions to be specialised/applied to various and specific 
TMN interfaces. 

The PLMN Management Architecture is largely based on TMN, and will reuse those functions, methods and interfaces 
already defined (or being defined) that are suitable for the management needs of a PLMN. However, the new challenges 
of 3G Telecom Management may require the exploration and incorporation of other concepts (other management 
paradigms widely accepted and deployed). 



5 General view of PLMN Management Physical 

architectures 

Telecom Management Architectures can vary greatly in scope and detail. The architecture for a large service provider, 
with a lot of existing legacy systems and applications, upon which many services are based, will be of high complexity. 
In contrast, the architectural needs of a start-up mobile operator providing its services to a small group of value-added 
Service Providers will be much less and will probably focus on more short-term needs. 

A mobile network operator has to manage many different types of networks as radio networks, exchanges, transmission 
networks, area networks, intelligent nodes and substantial amounts of computer hardware/software. This wide variety of 
network equipment will most probably be obtained from a variety of equipment vendors. The nature of a mobile radio 
network will be heterogeneous and will present a number of operational difficulties for the service provider on enabling 
effective and efficient network management. 

The standardisation work for the management of a PLMN has adopted the top-down approach and will from business 
needs identify functional and informational architectures. The physical architecture will have to meet these 
requirements and as there are many ways to build a PLMN it will vary greatly from one TMN solution to another. There 
will be many physical implementations, as different entities will take different roles in a PLMN. 

It is obvious that it will not be meaningful or even possible to fully standardise a common Telecom Management 
physical architecture for PLMNs. The present document will identify and standardise the most important and strategic 
contexts and serve as a framework to help define a physical architecture for a planned PLMN. 



6 Basic objectives for PLMN Management Physical 

Architecture 

The management of a 3G system will put a lot of new requirements to the management systems compared to the second 
generation of Mobile telephony. Some of the challenging requirements affecting the physical architecture are: 

- To be capable of managing equipment supplied by different vendors. 

- To enable TM automation in a more cost efficient way - TM optimised for maximum efficiency and 
effectiveness. 

- To provide PLMN configuration capabilities that are flexible enough to allow rapid deployment of services. 

- To report events and reactions in a common way in order to allow remote control. 
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- To allow interoperability between Network Operators/Service Providers for the exchange of 
management/charging information. 

- To be scaleable and applicable to both larger and small deployments. 

- Accessibility to information. 

- To profit from advances and standards in IT and datacom industry. 

The second generation of mobile networks can - from a management point of view - be characterised as the era of 
vendor-dependent NE managers. The different OSs had very low interoperability with other systems and functional 
blocks could rarely be re-used. The Mobile Telecom Management Networks were far away from the TMN vision where 
one vendor's OS should be able to manage other vendors" network elements. 

PLMN Organisations need cost-effective management solutions and better time to market focus. Interoperability, 
scalability and re-use are keywords for the new generation of management systems. 

Many of the new requirements on the management of PLMNs can only be solved by defining and establish a suitable 
physical architecture. Thou it is not possible to standardise the one single TM physical architecture, it is evidently so 
that the success of a Telecom Management Network of a PLMN Organisation will heavily depend on critical physical 
architectural issues. The present document will identify those architectural critical issues. 



7.1 



TM Architectural aspects 
Architectural relationship 



The basic aspects of a TM architecture, which can be, considered when planning and designing a TM network are: 

- The functional architecture. 
The information architecture. 

- The physical architecture. 

The management requirements - from the business needs - will be the base for the functional architecture, which will 
describe the functions that have to be achieved. The information architecture defines what information that has to be 
provided so the functions defined in the functional architecture can be achieved. The physical architecture has to meet 
both the functional architecture and the information architectures. Other constraints from realty will also have impact to 
the physical architecture as cost, performance, legacy systems and all preferences any operator will have on a big 
capital investment as a TM network. 



Business 
needs 




Information 
Architecture 



Figure 7.1 : Architectural relationship 
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7.2 Architectural constraints 

Large software systems, such as a network management system, are a capital investment that operators cannot afford to 
scrap every time its requirements change. Operators are seeking cost-effective solutions to their short-term needs. All 
these reality-related issues are vital constraints that should be addressed in the definition of the architecture. 

The standardisation of 3G systems will bring new and different services that will add new demands on 
telecommunications management. Every PLMN organisation will include different functionality depending on the role- 
played and the equipment used by that entity. Regulation may force some of the roles that shall be taken. The need to 
link systems across corporate boundaries will be a consequence of this. 

The rapid evolution of new services and technologies will also put requirements on the PLMN physical management 
architecture to accommodate market and technology trends. To future-proof investments and continuously be able to 
take advantage of new technologies are important constraints to the physical architecture. 

A PLMN TMN should also adopt an architecture that will achieve scalability and extensibility of systems and networks 
so the TMN can grow as the services expand over time. To start with a small TMN and easily be able to expand the 
TMN after new requirements will be important issues for most PLMN operators. 

The Telecom Management Network will be just one part of the overall business of a company. System management, 
general security issues and development strategies can be the target for company policies. System architectures and 
technology choices, as well as the availability of off-the-shelf commercial systems and software components that fulfil 
the requirements established in the present document, may be critical to an operator's implementation of the specified 
management architecture. 

7.3 Interoperability 

7.3.1 Introduction 

The new requirement on a 3G system TMN will imply a focus change from network element management towards 
management of information "information management". Network and service providers make use of different 
information in several different ways which also may vary from network to network and from time to time. Basic 
information as alarms is of course essential information for localising faults but may also be the key information to be 
able to set up a service with a service level agreement. 

Numerous of different interfaces can be identified in a PLMN network in the areas of network element management, 
network management and service management. The most important and complex of these interfaces will be 
standardised but many interfaces of less importance are unlikely to be fully standardised and will be up to the individual 
operator and vendor to develop. To adopt mainstream computing technologies, re-use widely used protocols, standards 
and an open system architecture will be essential to secure interworking between all physical entities in a PLMN. 

Low-cost and general access to management systems information will be needed. Obviously this is the critical issue and 
challenging task in the heterogeneous, distributed and complex network of a PLMN. 

7.3.2 Interfaces 

A PLMN will consist of many different types of components based on different types of technologies. There will be 
access-, core-, transmission- and service node networks and many of the components have already been the targets for 
Telecom Management standardisation at different levels. Many of these standards will be reused and the management 
domain of a PLMN will thereby consist of many TMNs. The architecture of PLMN TMNs should support distributed 
TMNs and TMN-interworking on peer-to-peer basis. 

The Telecom Management Architecture can vary greatly in scope and detail, because of scale of operation and that 
different organisations may take different roles in a PLMN (see clause 5). The architecture of PLMN TMNs should 
provide a high degree of flexibility to meet the various topological conditions as the physical distribution and the 
number of NEs. Flexibility is also required to allow high degree of centralisation of personnel and the administrative 
practices as well as allowing dispersion to administrative domains. The 3G Telecom Management architecture should 
be such that the NEs will operate in the same way, independently of the OS architecture. 
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Figure 7.2 illustrates the basic domains in a 3GPP system (identified in 3GPP Technical Standards [12], [13]), related 
management functional areas and introduces Interface-N (Itf-N). 
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Figure 7.2: Overview of 3GPP Telecom Management Domains and Itf-N 

Itf-N between the NE OSFs and NM/SM OSFs could be used by the network- and service management systems to 
transfer management messages, notifications and service management requests via the NE OSF to the Network 
Elements (NEs). 

This interface shall be open and the information models standardised. 

Telecom management interfaces may be considered from two perspectives: 

1) the management information model; 

2) the management information exchange. 

The management information models will be standardised in other 3 GPP documents but the management information 
exchange will be further described in this architectural standard. 

The management task will vary greatly between different network elements in a PLMN. Some NEs are of high 
complexity e.g. a RNC, while others e.g. a border gateway is of less complexity. Different application protocols can be 
chosen to best suite the management requirements of the different Network Elements and the technology used. 

Application protocols can be categorised out of many capabilities as: 

- Functionality; 
Implementation complexity; 

- Processor requirements; 

- Cost efficiency; 

- Market acceptance, availability of "off the shelf commercial systems and software". 

For each Telecom Management interface that will be standardised by 3 GPP at least one of the accepted protocols will 
be recommended. Accepted application protocols (e.g. CMIP, SNMP, CORE A HOP) are defined in TS 32.101 [2], 
annex A. 

7.3.3 Entities of a 3GPP system 

To provide the mobile service as defined in a 3GPP system, some specific functions are introduced [12]. These 
functional entities can be implemented in different physical equipments or gathered. In any case, exchanges of data 
occur between these entities and from the Telecom Management perspective they can all normally be treated as network 
elements. The basic telecom management functional areas such as fault management, configuration management, 
performance management and security management are all applicable to these entities. As such they are all the targets 
for 3 GPP Telecom Management technical standards. 
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As discussed in clause 5, there will be many possible ways to build a 3 GPP system and thereby many possible 
architectures of a mobile system. The entities presented in figure 7.3 should be treated as the fundamental building 
blocks of any possible implementation of a 3GPP system. 
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Figure 7.3: Examples of entities of the mobile system to be managed 

In figure 7.4 the prime domains for the standardisation effort of 3GPP Telecom Management are shown as shaded 
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Figure 7.4: High level 3GPP system Network architecture 



7.3.4 Open systems approach 



Even in the second generation of mobile radio networks the operators has to cope with heterogeneous environments in 
many different ways. No single vendor is likely to deliver all the management systems needed for a mobile operator. 

The many different types of network elements, some with very high management complexity as an exchange and some 
less complex as a repeater system, are generally supported with unique vendor specific management systems with very 
low interoperability. Duplicated TMN applications is another obvious reality of this generation of management systems. 
This will be further discussed under clause 9 (TMN Applications). 

The 3G requirements call for open systems that can be supported by the marketplace, rather than being supported by a 
single (or limited) set of suppliers, due to the unique aspects of the design chosen. Open systems architectures are 
achieved by having the design focus on commonly used and widely supported interface standards. This should ensure 
costs and quality that are controlled by the forces of competition in the marketplace. 

The open systems approach is a technical and business strategy to: 

- Choose commercially supported specifications and standards for selected system interfaces. 

- Build systems based on modular hardware and software design. 

Selection of commercial specifications and standards in the Open systems approach should be based on: 

- Those adopted by industry consensus based standards bodies or de facto standards (those successful in the 
market place). 

- Market research that evaluates the short and long term availability of products. 
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- Trade-offs of performance. 

- Supportability and upgrade potential within defined cost constraint. 

- Allowance for continued access to technological innovation supported by many customers and a broad industrial 
base. 

7.3.5 Level of openness 

The level the interfaces conform to open standards is critical for the overall behaviour. A low level of openness will 
severely impact on long-term supportability, interoperability, development lead-time, and lifecycle cost and overall 
performance. 

Interfaces are expensive parts in a TMN and interfaces with low level of openness severely impact on development 
lead-time for the introduction of any system, application component or service. Easy implementation (plug & play) is a 
requirement for TMN physical entities and requires a high the level of openness. 

7.3.6 Closed interfaces 

Many second-generation mobile network physical management entities have vendor controlled system/subsystem 
boundary descriptions that are not disclosed to the public or are unique to this single supplier - closed interfaces. 

Such interfaces will not fulfil the basic requirements of a 3G TMN. Closed interfaces can only be used as internal 
interfaces where no information what so ever has to be shared to other physical management entities. 

7.4 Data communication networks 

Within a TMN, the necessary physical connection (e.g. circuit- switched or packet-switched) may be offered by 
communication paths constructed with all kinds of network components, e.g. dedicated lines, packet- switched data 
network, ISDN, common channel signalling network, public-switched telephone network, local area networks, terminal 
controllers, etc. In the extreme case the communication path provides for full connectivity, i.e. each attached system can 
be physically connected to all others. 

The TMN should be designed such that it has the capability to interface with several types of communications paths, to 
ensure that a framework is provided which is flexible enough to allow the most efficient communications: 

- between NE and other elements within the TMN; 

- between WS and other elements within the TMN; 

- between elements within the TMN; 

- between TMNs; 

- between TMNs and enterprise. 

In this case the term efficiency relates to the cost, reliability and maintainability of the data transported. 

Two aspects impact costs. The first is the actual cost to transport data across the network between the TMN and the NE. 
The second aspect is the design of the interface including the selection of the appropriate communications protocol. 

Whatever standardised protocol suite at the networking level that is capable of meeting the functional and operational 
requirements (including the network addressing aspects) of the Logical and Application Protocol levels of a given 3GPP 
management interface, is a valid Networking Protocol for that interface. 

A number of requirements must be met by the Networking Protocol, as follows: 

- Capability to run over all supported bearers (leased lines, X.25, ATM, Frame Relay, ...) 

- Support of existing transport protocols and their applications, such as OSI, TCP/IP family, etc. 

- Widely available, cheap and reliable. 
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The Internet Protocol (IP) is a Networking Protocol that ideally supports these requirements. IP also adds flexibility to 
how management connectivity is achieved when networks are rolled out, by offering various implementation choices. 
For instance, these may take the form of: 

- Dedicated management intranets. 

- Separation from or integration into an operator's enterprise network. 

- Utilisation, in one-way or another, of capacities of the public Internet and its applications or other resources. 



7.5 New technologies 



Meeting application requirements in the most affordable manner together with development lead-time are important 
issues identified in early 3GPP management standardisation work. But the TMN functional, information and physical 
architectures should also keep pace with the introduction of new technologies, services and evolving network 
infrastructures. Technology is advancing so rapidly today that this should be a fundamental part of the physical 
architecture - to be able to easily adopt new important technologies. 

A 3GPP system will need to incorporate new successful technologies from the IT-world. Today distributed computing 
implementations have matured to a point where the goals of TMN can be realised using commonly available 
technologies for a reasonable cost. 

Widely accepted open standards and new IT-technologies will be indispensable to fulfil the challenging managing 
requirements of a 3 GPP system. 

New technologies in the IT business such as generic application components together with distributed processing 
technology are new important drivers upon application design of management systems. The possibility to purchase 
functional components from the open market are of great importance from many aspects such as cost-efficiency and 
time-to-market. 



8 3GPP Management Physical architectures 

A 3 GPP Telecom Management Network will consist of many different management layers and many different building 
blocks. The complexity will vary greatly in detail because every organisation has different needs. The following clause 
will identify the most critical architectural issues and compliance conditions for a given 3GPP management interface. It 
should serve as fundamental requirements for any 3 GPP entity (network element or management system) being a part of 
a 3GPP TMN. 



8.1 Compliance Conditions 



For a 3 GPP entity (management system or NE) to be compliant to a given management interface, all the following 
conditions shall be satisfied: 

1) It implements the management functionality specified in the relevant IRP Information Service specifications. 

2) It provides at least one of the IRP Solution Sets (were available) related to the valid Application Protocols 
specified by 3 GPP Application Protocols for that interface, [2] annex C. 

3) It provides at least one standard networking protocol. 

4) In case the entity does not offer the management interface on its own, a Q-Adapter shall be provided. This 
Q- Adapter shall be provided independently of any other NE and/or management system. 

5) Support for Bulk Transfer Application Protocols specified by the relevant 3 GPP management interface 
specifications applicable to that interface. 
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8.2 Network Element (NE) management architecture 

Figure 8.1 shows two possible options for management interface from the OS upper layers to NE. Option 1, provides 
access to the NE via element manager, and Option 2, provides a direct access. It is sufficient to provide one or the other. 

Figure 8.1 does not imply and limit the realisation of any OS physical block (e.g. E-OS, N-OS) to just one logical layer. 
OS physical blocks may span more than one logical layer (ITU-T Recommendation M.3010 [1]). Different types of 
network elements, different functional areas, operator and vendor preferences etc will put different constraints on the 
physical realisation of the OSFs. See further clause 9. 



Option 1 



OS Upper layers 




DOS 



OS Element 

Management 

LAYER 




(^^j DCN 

J 



Option 2 




OSF 





]^ etwork Element 



Fully standardized (3 GPP Management Application Protocol + 3 GPP Object Model) 
^— ^^ Open (3 GPP Management Application Protocol + Vendor defined Object Model) 

NOTE: 3 GPP Management Application Protocols are listed inSGPP TS 32.101 [2], Annex A. 



Figure 8.1 : Network Element Management Architecture 
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For a 3 GPP entity (Network Element or management system) to be compliant to a given management interface the 
following conditions shall all be satisfied: 



Item 


Compliance conditions 


1 


Implements relevant 3GPP IRP Information Service specifications. 

For an interface illustrated by the dashed line in figure 4 the object model is not standardised but it shall be open 


2 


Application protocol (e.g. CMIP,SNMP,CORBA MOP) 

(Defined in TS 32.1 01 [2], annex A) 

If 3GPP has specified one or more IRP Solution Sets corresponding to the IRP Information Services in item 1 

then at least one of those IRP Solution Sets shall be supported. 

(Defined in TS 32.101 [2], annex C) 


3 


Valid Network Layer Protocol 
(see annex B of TS 32.101 [2]) 


4 


Lower protocol levels required by Item 1 , 2 and 3 
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8.3 Subnetwork Management Architecture 

(Example 3GPP RNC / NodeB) 

An important special case of the network element management architecture is where one type of network element such 
as the RNC will need management information for co-ordination of a subnetwork of other types of network elements 
such as NodeB. 

This management information shared between the RNC and NodeB will not reach the operators and is not considered to 
be a part of the 3 GPP TMN. All other management information related to NodeB will transparently be transferred by 
the RNC towards the 3GPP TMN. 
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Figure 8.2: Subnetwork Management Architecture 

The same compliance conditions apply for the subnetwork management architecture as for the network element 
management architecture (see clause 8.2). 
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8.4 Operations Systems interoperability architecture 

Interoperability between operations systems is an important issue in a 3 GPP system. Different organisations may take 
different roles in a 3GPP system. The need to share information across corporate boundaries will be a consequence of 
this. 

The heterogeneous, distributed and complex network of a 3 GPP system will be a market for many different vendors. All 
operations systems have to interoperate and shall be able to share information. This is a critical issue in the management 
of third generation systems. 
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Figure 8.3: Operations Systems interoperability Arcliitecture 

For a Operations System to be 3GPP TMN compliant the following conditions shall all be satisfied: 



Item 


Compliance conditions 


1 


Implements relevant 3GPP IRP Information Service specifications. 


2 


Application protocol (e.g. CMIP,SNMP,CORBA MOP) 

(Defined in TS 32.1 01 [2], annex A) 

If 3GPP has specified one or more IRP Solution Sets corresponding to the IRP Information Services in item 1 

then at least one of those IRP Solution Sets shall be supported. 

(Defined in [2], annex C) 


3 


Valid Network Layer Protocol 
(see annex B of TS 32.101 [2]) 


4 


Lower protocol levels required by Item 1 ,2 and 3 
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8.5 Operations Systems intra-operability architecture 
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Figure 8.4: Operations Systems intra-operability Architecture 

I indicates an internal flow and is not standardised. 



OS-QExternai indicates an external flow and shall to be compliant to a given 3GPP Management Interface satisfy the 
following conditions: 



Item 


Compliance conditions 


1 


Implements relevant 3GPP IRP Information Service specifications. 


2 


Application protocol (e.g. CMIP,SNMP,CORBA MOP) 

(Defined in TS 32.1 01 [2], annex A) 

If 3GPP has specified one or more IRP Solution Sets corresponding to the IRP Information Services in item 1 

then at least one of those IRP Solution Sets shall be supported. 

(Defined in TS 32.101 [2], annex C) 


3 


Valid Network Layer Protocol 
(see annex B of TS 32.101 [2]) 


4 


Lower protocol levels required by Item 1 ,2 and 3 
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8.6 Business System interconnection architecture 

The business management layer has in the second-generation systems a very low degree of standardisation. Operators 
have legacy systems or more IT influenced systems often adopted to every organisations different needs. Business 
systems are not a part of a 3 GPP TMN. 
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Figure 8.5: Business Systems interconnection arcliitecture 

OS-QExterai indicates an external flow and shall to be compliant to a given 3GPP management interface satisfy the 
following conditions: 



Item 


Compliance conditions 


1 


Implements relevant 3GPP IRP Information Service specifications. 


2 


Application protocol (e.g. CMIP,SNMP,CORBA MOP) 

(Defined in TS 32.1 01 [2], annex A) 

If 3GPP has specified one or more IRP Solution Sets corresponding to the IRP Information Services in item 1 

then at least one of those IRP Solution Sets shall be supported. 

(Defined in TS 32.101 [2], annex C) 


3 


Valid Network Layer Protocol 
(see annex B of TS 32.101 [2]) 


4 


Lower protocol levels required by Item 1 ,2 and 3 



IFx indicates an external flow and shall to be compliant to a given 3 GPP management interface satisfy the following 
condition: 



Item 



Compliance conditions 



Not standardised but open 
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TMN applications 



Telecom management applications can be implemented in many different ways depending on constraints presented in 
previous clauses of the present document. Consistent operational processes are required for the management of the 
network irrespective of vendor equipment. A mobile operator can because of the very heterogeneous nature of their 
networks easily end of with dozens of duplicated applications for e g alarm surveillance. Most vendors of network 
equipment offers dedicated net-element managers and the ones not built with an open system approach will severely 
limit the possibility to report and manage the network in a consistent way. 

Network element vendors with closed and unique network element managers or operations systems with closed 
interfaces or interfaces with low level off openness will not fulfil the basic requirements as a part of a 3G system. It will 
not be possible to design and build the Telecom Management Network to support the operational processes as required. 
Such physical entities are not under consideration in the present document. 

Many TM application functions can be identified as generic functions used by all major types of telecom equipment. 
Alarm surveillance applications and performance analysing applications are generic necessities to manage most network 
elements. Security and system management applications are also common to many TM components and may be the 
scope for overall business policies. 

To identify and specify the design criteria that will allow re-usable application components to be developed across 
multiple telecom business scenarios are important issues to fulfil the basic 3G Management requirement. "To minimise 
the costs of managing a PLMN such that it is a small component of the overall operating cost" . 

The implication of the top down approach in the standardising work of 3G is that consistent operational management 
processes are required irrespective of vendor equipment. 

Generic management applications is required to facilitate: 

- Reduced management application development costs. 

- Simplification of operational processes and associated reduction in costs. 

- Reduced time to deploy new services as management systems already exist. 

- Consistent representation of basic information. 
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Figure 9.1 : Unique NE Fault Management 

Figure 9.1 represents a very common situation in the management of second generation of mobile networks. Different 
vendors supplied their network elements with unique net-element managers. The interfaces were mostly proprietary or 
unique. The information models for generic information such as alarms were rarely standardised. All together the 
consequence for the operators became very complex. Similar information at many levels, repeated acknowledge of 
alarms, inconsistent representation of similar information are a few of all the difficulties the operators had to cope with. 

Some of the more severe implication of this situation is the difficulty to add more intelligence into the applications to 
better support the processes of the network providers. The operators who tried to brake up this situation had to put in a 
lot of effort into software development and proprietary interfaces. The marketplace did not support the needs of the 
operators. 
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Figure 9.2: Generic Fault Management 

Figure 9.2 indicates the situation were the Telecom Management process alarm surveillance is supported by a generic 
application for Fault Management. A common information model and accessibility to all related information will make 
it possible to add more intelligence to the management systems and to better support the management task. 

TMN application functions such as billing information collection or configuration management of a specialised network 
element are examples of application that can be identified as unique applications. Even these applications will need to 
interoperate with other applications and will also need the open system approach to be a part of a 3G TMN. With a 
network with many different types of network elements a common graphical user interface such as a web browser for 
configuration management applications could be an important issue to create consistent operational processes. 

The complexity and heterogeneous nature of a 3G system calls for easy integration (plug&play) of HW/SW. 
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1 Void 

1 1 Implementation aspects 

PLMN operators might categories and organise its operation systems in many different ways as: 

- A national fault and performance OS. 

- A national charging, billing and accounting OS. 

- Regional configuration OS. 

- Regional fault, performance and configuration OS. 

- etc. 

This geographical dependent categorisation may change after time and the growth of the network. A physical 
architecture based on an open system design and re-usable application components would ease the work to adopt such 
structural changes. A management system build for a PLMN shall provide the possibility of layering the applications. 

12 3GPP TMN Conformance 

The goal of TMN conformance (see ITU-T Recommendation M.3010 [1]) is to increase the probability that different 
implementations within a TMN will be able to interwork, that TMNs in different service/network provider's 
administrations and customer's system will be able to interwork as much as agreed on. 

TMN conformance are testable conditions. 

It is only the requirements on the external behaviour that have to be met by the conformance statements. 

To finally guarantee interoperability the purchaser/user shall be able to test and verify that any two systems, claiming 
any type of TMN conformance, interoperate. Interoperability testing shall include: 

- Testing of the interface protocols; 

- The shared/exposed information over those interfaces; 

- The interface functionality of the system. 

A 3GPP TMN conformant entity shall support necessary information to support such interoperability testing namely: 

- Statements made by the supplier of an implementation or system claimed to conform to a given specification, 
stating which capabilities and options have been implemented. 

- Detailed information to help determine which capabilities are testable and which are un-testable. 

- Information needed in order to be able to run the appropriate test. 

- The system interface documentation shall list the documents that define the specified information models with 
the inclusion of the version number and date. 

- Necessary information about vendor supplied extensions of a standardised interface 

The interface specification shall be documented, publicly available and licensable at reasonable price on a non- 
discriminatory basis. 

Specific conformance guidelines shall be included in the different IRP solution sets. A 3 GPP TMN conformant entity 
must support information stated in those conformance guidelines. 
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13 TMN planning and design considerations 

A TMN should be designed such that it has the capabiHty to interface with several types of communications paths to 
ensure that a framework is provided which is flexible enough to allow for the most efficient communications: 

- Between one NE and other elements within the TMN; 
Between a WS and other elements within the TMN; 

- Between elements within the TMN; 

- Between TMNs. 

The basis for choosing the appropriate interfaces, however, should be the functions performed by the elements between 
which appropriate communications are performed. The interface requirements are specified in terms of function 
attributes needed to provide the most efficient interface. 

13.1 Function attributes 

a) Reliability - The capability of the interface to ensure that data and control are transferred such that integrity and 
security are maintained. 

b) Frequency - How often data is transferred across the interface boundary (Normal behaviour). 

c) Quantity - The amount of data that is transferred across the interface during any transaction. 

d) Priority - Indicates precedence to be given to data in case of competition for network resources with other 
functions. 

e) Availability - Determines the use of redundancy in the design of the communications channels between 
interfacing elements. 

f) Delay - Identifies the amount of buffering that may be tolerable between interfacing elements. This also impacts 
communications channel designs. 

Table 13.1 suggests a possible ranges for these function attributes. 

Table 13.1 : Possible ranges for TMN function attributes [1] 



Attributes 


Requirements 


Nature of attributes 


Performance or grade of service (P) 


Delay (speed) 


Short 

Medium 

Long 


Objective of design and control 
(acceptable/unacceptable but 
available/unavailable) 


Reliability (accuracy) 


High 

Medium 

Low 


Availability 


High 

Medium 

Low 


Characteristics of TIVIN traffic (C) 


Quantity 


Large 

Medium 

Small 


Condition or parameter of design 


Frequency 


Often continuous 

Periodic 

Sparse 


Priority 


High 

Medium 

Low 
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13.2 Functional characteristics 

Each major type of telecommunications equipment has functional characteristic needs that can be used to describe the 
complexity of the interface. 

There are, however, a basic group of TMN application functions that cross all major types of telecommunications 
equipment. There are also unique TMN application functions that are performed by specific categories of major 
telecommunications equipment. Alarm surveillance is an example of the former, whereas billing information collection 
is an example of the latter. 

Functional characteristics of the elements within a TMN, e.g. OS, DCN and MD also describe the complexity of 
interfaces between these elements. 

13.3 Critical attributes 

Attribute values for a given function are generally consistent across the network elements. 

When considering a single interface, it is important to identify the controlling attribute ranges for the design of the 
interface. 

If there are conflicting attribute values for different functions in a given network element, more than one instance of an 
interface may be needed. 

Overall TMN attribute values for the interfacing of elements within the TMN depend on the type and number of 
functions performed within these elements. In this case the functions are not consistent across TMN elements, but are 
controlled by the individual TMN design of an Administration. 

13.4 Protocol selection 

In many cases, more than one protocol suite will meet the requirements for the network element or TMN element under 
consideration. It is the approach for the 3 GPP Telecom management standardisation to concentrate on protocol 
independent information models, allowing the mapping to several protocol suites. 

The rationale behind this is: 

The blurring of Information and Telecommunication technologies in a 3G system, it is required to work on a 
more open approach (acknowledging the market status and foreseen evolutions). 

- The lifecycle of information flows is 10 to 20 years, while the protocols is 5 to 10 years. 

- The developments on automatic conversion allows for a more pragmatic and open approach. 

The choice of the individual protocol from the recommended family will be left open to the vendors and operators. 

To provide the most efficient interface care should be taken to select the protocol suite that optimises the relationship 
between the total cost to implement that protocol suite, the functional attributes and the data communications channels 
that carry the information across the interface. 

1 3.5 Communications considerations 

DCN architectures should be planned and designed to ensure that their implementation provides appropriate degrees of 
availability and network delay while minimising cost. 

One should consider the selection of communications architectures, e.g. star, multipoint, loop, tree, etc. 

The communications channels, e.g. dedicated lines, circuit-switched networks and packet networks used in providing 
the communications paths, also play an important role. 



ETSI 



3GPP TS 32.102 version 7.1.0 Release 7 



31 



ETSI TS 132 102 V7.1.0 (2007-06) 



1 4 Mediation/Integration 



The increase in the need to incorporate a hybrid set of technologies, multiple protocols and heterogeneous resources 
requires the availability of open management interfaces between the management systems and the different network 
resources. These interfaces require an underlying mechanism to mediate - interpret, translate, and handle data - between 
the various data representations and protocols. A set of Technology Integration Points [10] can be identified and will 
need to be supported. 

Software components on the open market as automatic conversion applications, gateways, mediation applications will 
be valuable products to fulfil the challenging task to incorporate multiple protocols and heterogeneous resources. 

Figure 14.1 summarises Technology Integration Points for some technologies: 

Internet 
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CORBA Services 

Object Request Broker 



Manager / Agent Environment 



AppHcation Objects CORBA Facilities Domain I/Fs 

QQ QQ Q^ 
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Figure 14.1 : Technology Integration Points [10] 

Essentially, figure 14.1 indicates that from the technologies selected, three technology areas will need to be integrated. 
These are: 

- InternetAVeb based services; 

- Object Request Broker (CORBA) based services; 

- Telecom based Manager/Agent services (i.e. CMIP/GDMO and SNMP/SMI). 

In order to provide adequate points of integration between these areas of technology, five Integration Points (IPs) have 
been identified - as outlined in table 14.1: 
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Table 14.1 : Technology Integration Points [10] 





Managed Objects 
(GDMO/SMI) 


Management 

Services 
(CMISE/SNMP) 


Java Objects 


Web Browser 
(HTTP/HTML) 


TMN Agent 


CORBA Objects 


IP1 




IP4 


IPS 




CORBA Services 




IP2 








TMN Manager 










IPS 


IP1 Provides mapping of objects defined in CORBA/IDL to managed objects defined in GDIVIO or SIVII. 

IP2 Provides mapping of appropriate CORBA Services to CIVIIS and SNIVIP services. 

IPS Provides a mapping of Web Browser technology access to CORBA objects (for situations where this may be 
needed as an addition to/replacement of Browser access to a database). 

IP4 Provides a mapping between Java based objects and CORBA objects. 

IPS Provides a high level convenient programming interface for the rapid development of TMN based 

manager/agent interactions. It also provides a convenient point of integration if it is necessary to separate out 
the two sides of the manager/agent interface from the point of view of technology selection. For example, 
allowing the manager role to perhaps be supported in a Web-based environment, but giving a good point of 
integration with a TMN based agent. 
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Annex A (informative): 
Technology considerations 

A.1 TIVIN physical blocks 

TMN functions can be implemented in a variety of physical configurations (ITU-T Recommendation M.3010 [1]). The 
relationship of the functional blocks to physical equipment is shown in table A. 1 which names the TMN physical blocks 
according to the set of function blocks which each is allowed to contain. For each physical block there is a function 
block which is characteristic of it and is mandatory for it to contain. There also exist other functions, which are optional 
for the physical blocks to contain. Table A.l does not imply any restriction of possible implementations, but defines 
those identified within this annex. 

The subclauses below give the definitions for consideration in implementation schemes. 

Table A.1 : Relationship of TMN physical block names to TMN function blocks 



(note 2 & note 3) 


NEF 


TF 


OSF 


WSF 


NE 


M 









(see note 3) 


QA, XA, QM, XM 




M 






OS 







M 





WS 








M 


M Mandatory 

Optional 

NOTE 1 : Within this table, where more than one name is possible, the choice of the physical block name is 

determined by the predominant usage of the block. 
NOTE 2: TMN physical blocks may contain additional functionality, which allows them to be managed. 
NOTE 3: For the WSF to be present the OSF shall also be present. This means that the WSF shall address an 

OSF. The local man-machine access is not considered part of the TMN. 



A. 1 . 1 Operations System (OS) 

The OS is the system, which performs OSFs. The OS may optionally provide QAFs and WSFs. 

A. 1.2 Transformation 

Transformation provides conversion between different protocols and data formats for information interchange between 
physical blocks. There are two types of transformation: adaptation and mediation that can apply at q or x reference 
points. 

A.1 .2.1 Adaptation device 

An Adaptation Device (AD), or adapter, provides transformation between a non-TMN physical entity to a NE to OS 
within a TMN. A Q-adapter (QA) is a physical block used to connect NE-like or OS-like physical blocks with 
non-TMN compatible interfaces (at m reference points) to Q interfaces. An X-adapter (XA) is a physical block used to 
connect non-TMN physical entities having a non-TMN communication mechanism in a non-TMN environment to an 
OS at the edge of a TMN. 

A.1 .2.2 Mediation Device (MD) 

A Mediation Device (MD) provides transformation between TMN physical blocks that incorporate incompatible 
communication mechanisms. A Q-Mediation Device (QMD) is a physical block that supports connections within one 
TMN. An X-Mediation Device (XMD) is a physical block that supports connections of OSs in different TMNs. 
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A.1 .3 Network Element (NE) 



The NE is comprised of telecommunication equipment (or groups/parts of telecommunication equipment) and support 
equipment or any item or groups of items considered belonging to the telecommunications environment that performs 
NEFs. The NE may optionally contain any of the other TMN function blocks according to its implementation 
requirements. The NE has one or more standard Q-type interfaces and may optionally have F and X interfaces. 

Existing NE-like equipment that does not possess a TMN standard interface will gain access to the TMN via a Q 
Adapter Function, which will provide the necessary functionality to convert between a non-standard and standard 
management interface. 

NEs may be distributed or centralised. Various parts of a NE are not geographically constrained to one physical 
location. For example, the parts may be distributed along a transmission system. An example of a distributed NE is 
illustrated in figure A.l (ITU-T Recommendation M.3010 [1]). 
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Figure A.1 : Distributed network element 



A. 1.4 Workstation (WS) 



The WS is the system, which performs WSFs. The workstation functions translate information at the f reference point to 
a displayable format at the g reference point, and vice versa. 

If equipment incorporates other TMN functionality as well as the WSF, then it is named by one of the other names in 
table A.l 

A.1 .5 Data Communication Network (DCN) 

A DCN supporting a TMN has traditionally conformed to the network service of the OSI reference model for ITU-T 
applications as specified in ITU-T Recommendation X.200 [4]. ITU-T Recommendation X.25 has been a commonly 
used packet protocol. However, the evolution of telecommunication services is merging circuit- switched and packet- 
switched modes with advancing technologies of ISDN, ATM, SDH, and the Internet. A variety of telecommunications 
services can be employed as long as integrity of information transfer can be preserved. 

Within a TMN, the necessary physical connection, such as circuit-switched or packet- switched, may be offered by 
communication paths constructed with various network components, including dedicated lines, X.25 packet- switched 
data network, ISDN, common channel signalling network, public- switched telephone network, local area networks, 
terminal controllers, etc. The facilities can be either dedicated to a DCN or shared resources (for example, using SS 
No. 7 or an existing X.25 or IP-based packet- switched network). 

Equipment supporting an OSF shall provide for two modes of data communication. These are spontaneous transmission 
of messages (e.g. for the NEF to the OSF) and a two-way dialogue (e.g. as the OSF obtains supporting information from 
the NEF and sends commands to the NEF or transfer messages to or from another OSF). In addition, an OSF is 
responsible for assuring the integrity of the data channels through a DCN. Physical connectivity in a local environment 
may be provided by a variety of subnetwork configurations including point-to-point, star, bus or ring. 

The DCN may consist of a number of individual subnetworks of different types, interconnected together. The DCN may 
be a local path or a wide-area connection among distributed physical blocks. The DCN is technology independent and 
may employ any single or combination of transmission technologies. 
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A.1 .6 TMN logical layered architecture within the TMN physical 
architecture 

Four specialisations of the OS physical block are defined to support a physical realisation of function blocks in logical 
layers. The four specialised OS physical blocks are the Business (B-OS), the Service (S-OS), the Network (N-OS) and 
the Element (E-OS) Operations Systems. These physical blocks are named according to the predominant function block 
they contain. Specifically, B-OS, S-OS, N-OS and E-OS predominantly contain B-OSF, S-OSF, N-OSF and E-OSF 
respectively. When physical blocks contain more than one kind of specialised OS function block that provide 
substantial functionality to the physical block, thus spanning more than one logical layer, the physical block is named 
according to the highest hierarchically layered function block. For example, a physical block containing both N-OSF 
and E-OSF, providing substantial network functionality is called an N-OS. 

The exchange of management information between logical layers employs the managing roles and managed roles of the 
TMN interaction model. This allows management activities to be clustered into layers and to be decoupled. The 
managed roles will be associated with a set of information elements from information model(s) exposing a view at the 
layer's level of abstraction (e.g. equipment, element, network, service, etc.). Generally, managing and managed roles 
may be placed in logical layers without restriction. A managed role may be associated with a set of information 
elements from any layer. Managed roles may be placed in any layer and invoke operations associated with any other 
managed roles. 

A.1 .7 Interoperable interface concept 

In order for two or more TMN physical blocks to exchange management information they shall be connected by a 
communications path and each element shall support the same interface onto that communications path. 

It is useful to use the concept of an interoperable interface to simplify the communications problems arising from a 
multi-vendor, multi-capability network. 

The interoperable interface defines the protocol suite and the messages carried by the protocol. Transaction-oriented 
interoperable interfaces are based upon an object-oriented view of the communication and therefore, all the messages 
carried deal with object manipulations. It is the formally defined set of protocols, procedures, message formats and 
semantics used for the management communications. 

The message component of the interoperable interface provides a generalised mechanism for managing the objects 
defined for the information model. As part of the definition of each object there is a list of management operations types 
which are valid for the object. In addition, there are generic messages that are used identically for many classes of 
managed objects. 

In the architecture, what predominantly distinguishes one interface from another is the scope of the management 
activity that the communication at the interface shall support. This common understanding of the scope of operation is 
termed Shared Management Knowledge. Shared Management Knowledge includes an understanding of the information 
model of the managed network (object classes supported, functions supported, etc.), management support objects, 
options, application context supported, etc. The Shared Management Knowledge ensures that each end of the interface 
understands the exact meaning of a message sent by the other end. 
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A.2 TMN standard interfaces 



Figure A. 2 shows an example of a physical architecture. It represents each of the functions as physical blocks and 
illustrates how a number of interfaces might share communication paths within a given TMN physical architecture. 
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Figure A.2: Examples of interfaces for the TMN physical architecture M.3010 [1] 

Figure A.2 shows the interconnection of the various TMN physical blocks by a set of standard interoperable interfaces. 
The allowable interconnections of these standard interfaces within a given TMN may be controlled by both the actual 
interfaces provided and/or by security and routing restrictions provided within the various physical block entities 
(e.g. passwords, log-ons, DCN routing assignment, etc.). 

TMN standard interfaces are defined corresponding to the reference points. They are applied at these reference points 
when external physical connections to them are required. 

There is a family of protocol suites for each of the TMN interfaces: Q, X and F. The choice of the protocol is dependent 
on the implementation requirements of the physical configuration. 

A.2.1 Q interface 

The Q interface is applied at q reference points. 

To provide flexibility of implementation, the class of Q interfaces is made up of the following subclasses: 

- the interface Q is applied at the q reference point; 

the Q interface is characterised by that portion of the information model shared between the OS and those TMN 
elements to which it directly interfaces. 
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A.2.2 F interface 

The F interface is applied at f reference points. The F interfaces connecting workstations to the TMN building blocks 
containing OSFs or MFs through a data communication network are included in the present document. Connections of 
implementation specific, WS-like entities to OSs or NEs, are not subject of the present document. 

A.2.3 X interface 

The X interface is applied at the x reference point. It will be used to interconnect two TMNs or to interconnect a TMN 
with other network or systems which accommodates a TMN-like interface. As such, this interface may require 
increased security over the level, which is required by a Q-type interface. It will therefore be necessary that aspects of 
security are addressed at the time of agreement between associations, e.g. passwords and access capabilities. 

The information model at the X interface will set the limits on the access available from outside the TMN. The set of 
capabilities made available at the X interface for access to the TMN will be referred to as TMN Access. 

Additional protocol requirements may be required to introduce the level of security, non-repudiation, etc. which is 
required. 

A.2.4 Relationship of TMN interfaces to TMN physical blocks 

Table A.l defines the possible interfaces, which each named TMN physical block can support. It is based upon the 
function blocks which table A.l associates with each physical block and the reference points between function blocks. 
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Annex B (informative): 
Overview of a 3GPP System 



Figure B.l presents an example of a 3GPP System, related management areas and introduces some management 
interfaces. 3GPP Service specific entities are not shown. 



OSF 
Terminal 



OSF 
UTRAN 



OSF 
GSM NSS 



OSF 
GSM BSS 



OSF 
GPRS NE's 



Itf-Band 
Itf-R 



ltf-G2 



ltf-G3 




Figure B.1 : Overview of a 3GPP System, showing management interfaces and management areas 

All the following interfaces are illustrated in figure B.l: 

- Itf-T between a terminal and a NE Manager. This interface will in some extent manage the 3G terminal and the 
USIM of the subscriber. Requirements of this interface are for further study. 

- Itf-B and Itf-R between UTRAN and a NE Manager. 

- Itf-Gl between GSM NSS and NE Manager. 

- Itf-G2 between GSM BSS and NE Manager. This interface is standardised in GSM 12-series specifications. 

- Itf-G3 between GPRS NEs and a NE Manager. 
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Annex C (informative): 
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